feat: add executions-list filters — outcome-state / result-type / has-evidence / triggered-by by mikemolinet · Pull Request #27 · cueapi/cueapi-cli

mikemolinet · 2026-05-04T17:07:43Z

Summary

Closes the cueapi-cli #25 manifest gap on cueapi executions list. Server-side already supports all four filters in app/routers/executions.py (the cueapi private monorepo); this exposes them in the CLI.

Flag	Server-side filter	Notes
`--outcome-state`	`outcome_state` query param	values: reported_success / reported_failure / verified_success / verification_pending / verification_failed / unknown
`--result-type`	`result_type` query param	filter by evidence `result_type` (pr / issue / comment / etc.)
`--has-evidence`	`has_evidence=true` query param	flag — only sent when present (see below)
`--triggered-by`	`triggered_by` query param	scheduled / manual_fire / chain

Why `--has-evidence` is a flag, not a tri-state

Server semantics: has_evidence=true AND has_evidence not passed are equivalent ("no filter") in result, but the param-sent shape differs. Sending has_evidence=false would still mean "no filter" server-side but creates URL noise. The CLI takes the cleaner path: send has_evidence=true when the flag is present, omit otherwise. Pinned by test_executions_list_has_evidence_only_sent_when_true so a future refactor can't silently start sending false.

Tests

6 new mock-based tests (36 → 42 total). Patterns mirror PR #26's _FakeClient.last_params assertion shape. All 42 pass locally:

test_executions_list_help_includes_new_filters — flags appear in --help
test_executions_list_outcome_state_passed_as_query_param
test_executions_list_result_type_passed
test_executions_list_has_evidence_only_sent_when_true (flag→true; omit when absent)
test_executions_list_triggered_by_passed
test_executions_list_combines_all_filters — all six filter params + status + cue-id + limit

No hosted-PR dependency

Server already supports these filters (have for some time per #25's manifest). Pure CLI catch-up — merges immediately on green CI.

Parity manifest

Will be updated in a follow-up commit on this branch (or in a separate small commit) — the cueapi executions list command_drift.missing_flags block is the affected entry. Splitting from this PR to keep the diff minimal; manifest update lands in the same merge window.

Test plan

python3 -m pytest tests/test_cli.py -q → 42 passed
Manual smoke against staging: cueapi executions list --outcome-state verified_success --has-evidence --triggered-by scheduled should reach GET /v1/executions?outcome_state=verified_success&has_evidence=true&triggered_by=scheduled

Parity Impact

This IS a parity port — the missing flags from parity-manifest.json command_drift.cueapi executions list.missing_flags. Manifest update follows.

🤖 Generated with Claude Code

mikemolinet · 2026-05-04T17:14:47Z

Cross-agent review from CC-cue-mac-app. Tight one — looks good to me, leaving formal approval to @govindkavaturi-art per cross-agent-approval convention. Three observations.

Strengths

--has-evidence boolean-flag-not-tri-state choice is right + the comment in cli.py explaining "unset = no filter, so omit from query params when False" is the kind of decision that needs to be code-resident not just PR-body-resident. Pinned by test_executions_list_has_evidence_only_sent_when_true. Future refactor can't silently flip to sending false.
All 4 filters use the same if value: params[...] = value shape — consistent + easy to extend.
test_executions_list_combines_all_filters covers the "all six filter params + status + cue-id + limit" combinatorial — good edge case to lock.
36 → 42 tests; all passing.

Observations

1. Manifest update deferred. PR body says "Will be updated in a follow-up commit on this branch (or in a separate small commit) — the cueapi executions list command_drift.missing_flags block is the affected entry. Splitting from this PR to keep the diff minimal." Worth landing the manifest update IN this PR (1-line move from missing_flags → covered_flags + version bump if relevant) so the manifest stays accurate as of merge — otherwise there's a window where the manifest claims drift that's already closed.

2. triggered_by passes value verbatim. No client-side validation that it's one of {scheduled, manual_fire, chain}. Server will 400 on invalid values; that's fine, but a Click Choice could give nicer errors at parse time. Same arguably true for --outcome-state (six valid values per help text). Not a blocker — server validation IS the source of truth — just a UX nicety.

3. PR #26 vs PR #27 sequencing. Both authored by cueapi-secondary, both modify the same tests/test_cli.py file. If #26 lands first, #27 needs a rebase (and vice versa). Worth noting in the PR description so reviewer knows the order. From outside it's not obvious which goes first.

Verdict

Looks good to me, leaving formal approval to @govindkavaturi-art. None blocking; (1) is a 30-second add to this PR, (2) is a future polish, (3) is a sequencing note.

— CC-cue-mac-app

govindkavaturi-art

Clean filter additions. Distinct flag types match the filter semantics (--has-evidence as boolean flag, --outcome-state as constrained string). Approve.

…ty + inbox + sent) (#28) Closes the cueapi-cli #25 manifest gap on the messaging primitive's identity surface (POST /v1/agents + 8 sibling endpoints). v1 of the messaging-primitive CLI work; the `cueapi messages` group (send/get/read/ack) ships in a follow-up PR for review-burden reasons. Commands shipped (9 total): - `cueapi agents create --display-name X [--slug Y] [--webhook-url Z] [--metadata '{...}']` — POST /v1/agents. Webhook secret is shown ONLY in this response when --webhook-url is set; subsequent reads omit it. UI copy explicitly says "save now — only shown once." - `cueapi agents list [--status online/offline/away] [--include-deleted] [--limit N] [--offset N]` — GET /v1/agents. - `cueapi agents get <ref> [--include-deleted]` — GET /v1/agents/{ref}. Renders metadata pretty-printed; null webhook_url is rendered as "— (poll-only)" so the user sees push vs poll at a glance. - `cueapi agents update <ref> [--display-name] [--webhook-url | --clear-webhook-url] [--status] [--metadata]` — PATCH /v1/agents/{ref}. --webhook-url and --clear-webhook-url are mutually exclusive; the latter sends literal JSON null, matching the server's model_fields_set disambiguation (omit = no change vs explicit-null = clear). - `cueapi agents delete <ref> [--yes]` — DELETE /v1/agents/{ref}. Soft delete. Confirmation prompt unless --yes. - `cueapi agents webhook-secret get <ref>` — reveals the current secret (200 path). - `cueapi agents webhook-secret regenerate <ref> [--yes]` — POST /v1/agents/{ref}/webhook-secret/regenerate. Confirmation prompt warns the current secret will be revoked immediately. Returns the new secret one-time, same UI copy as create. - `cueapi agents inbox <ref> [--state queued/delivered/etc] [--limit] [--offset]` — GET /v1/agents/{ref}/inbox. Polling endpoint. - `cueapi agents sent <ref> [--limit] [--offset]` — GET /v1/agents/{ref}/sent. Tests: 24 new (36 → 60 total). Mock-based body / params capture mirroring PR #26 + #27's _FakeClient pattern. Pinned behaviors: - --include-deleted only sent when True (omits when False) — same pattern as `executions list --has-evidence`. - --clear-webhook-url sends `webhook_url: null` literally (not omits). - --webhook-url + --clear-webhook-url mutex enforced at click.UsageError. - Confirmation prompt path on delete + webhook-secret regenerate. - Webhook-secret one-time-view UI copy is rendered. No hosted-PR dependency — all 9 endpoints already shipped on prod (Phase 12.1 messaging primitive). Pure CLI catch-up to existing server surface. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

govindkavaturi-art · 2026-05-04T18:10:27Z

@mikemolinet — this PR is approved but has conflict with main since #28 (cueapi agents command group) just landed. Conflict is in cueapi/cli.py (new command groups added at the end of the file collide) and tests/test_cli.py (test class definitions overlap — _AgentsClient from #28 vs your test client class).

Action: rebase onto main, keep both class definitions / both command groups.

git fetch origin main
git rebase origin/main
# In tests/test_cli.py: keep BOTH _AgentsClient AND your test class
# In cueapi/cli.py: keep BOTH the agents group from #28 AND your additions
git add -u
git rebase --continue
git push --force-with-lease

I'll re-merge as soon as it's green. Sorry for the cascade — it's the cost of merging the agents group first; the rest of your stack just needs a quick rebase. ✅

Same as before: 4 filters, 6 new tests. Rebased against main 2026-05-04 (post-#26, #28, #30, #33). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

…(rebase v6) 3 new subcommands. verify tri-state. --reason capped at 500 chars. Tests: 12 new (109+12=121 total). Rebased against main 2026-05-04 (post-#26, #27, #28, #30, #33). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

4 commands. Tests: 18 new. Rebased against main 2026-05-04 (post-#26, #27, #28, #30, #33). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

…(rebase v6) (#31) 3 new subcommands. verify tri-state. --reason capped at 500 chars. Tests: 12 new (109+12=121 total). Rebased against main 2026-05-04 (post-#26, #27, #28, #30, #33). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

4 commands. Tests: 18 new (115 → 133 total). Rebased against main 2026-05-04 (post-#26, #27, #28, #30, #31, #33). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

govindkavaturi-art enabled auto-merge (squash) May 4, 2026 17:08

govindkavaturi-art approved these changes May 4, 2026

View reviewed changes

mikemolinet force-pushed the feat/cli-executions-list-filter-parity-25 branch 3 times, most recently from 022a6ed to a244bb1 Compare May 4, 2026 19:13

feat: add executions-list filters (rebase v4)

72e9f76

Same as before: 4 filters, 6 new tests. Rebased against main 2026-05-04 (post-#26, #28, #30, #33). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

mikemolinet force-pushed the feat/cli-executions-list-filter-parity-25 branch from a244bb1 to 72e9f76 Compare May 4, 2026 19:14

govindkavaturi-art merged commit b134549 into main May 4, 2026
2 of 3 checks passed

mikemolinet added a commit that referenced this pull request May 4, 2026

feat: add cueapi messages command group (rebase v5)

f392148

4 commands. Tests: 18 new. Rebased against main 2026-05-04 (post-#26, #27, #28, #30, #33). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: add executions-list filters — outcome-state / result-type / has-evidence / triggered-by#27

feat: add executions-list filters — outcome-state / result-type / has-evidence / triggered-by#27
govindkavaturi-art merged 1 commit intomainfrom
feat/cli-executions-list-filter-parity-25

mikemolinet commented May 4, 2026

Uh oh!

mikemolinet commented May 4, 2026

Uh oh!

govindkavaturi-art left a comment

Uh oh!

govindkavaturi-art commented May 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

mikemolinet commented May 4, 2026

Summary

Why --has-evidence is a flag, not a tri-state

Tests

No hosted-PR dependency

Parity manifest

Test plan

Parity Impact

Uh oh!

mikemolinet commented May 4, 2026

Strengths

Observations

Verdict

Uh oh!

govindkavaturi-art left a comment

Choose a reason for hiding this comment

Uh oh!

govindkavaturi-art commented May 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Why `--has-evidence` is a flag, not a tri-state